Understanding Process Workflows
Throughout iMIS, there are many examples of workflow processes:
■ Processing orders through order entry, confirmation, approval, shipping, shipping notification, invoicing
■ Processing a member application
■ Signing up an exhibitor and following and tracking the process through the various contracts and order requirements
■ Processing opportunities
■ Issue Management
■ Marketing campaigns
■ Timed responses to inactivity
■ Multi-part mailings: Letters and labels to go with the letters
These are examples of what we will call “process workflow” and generally are thought of as “persistent workflows,” which may take a few minutes, days, or even months to complete.
Workflows typically:
■ Have an ownership structure.
■ Are related to a specific parent object, like an order, complaint, and so on.
■ Has a set of tasks that must be executed according to business rules.
Workflow Engine components
To deal with this pattern of needs on a consistent basis, iMIS provides a Workflow Engine.
There are two primary components of the workflow engine:
■ Process Definition Rules. Process definitions list all of the tasks for the workflow as well as the rules as to when the tasks are to be executed, and what the subsequent actions are to be initiated upon task completion. Tasks need not all execute serially. For instance, a workflow may have a step that requires approval from multiple sources, not necessarily sequentially.
■ Workflow Instances. Workflow instances are the actual workflows in action. Workflows may carry their own process definition rules within, or may simply refer to the standard definition for the workflow type. When rules are carried by the workflow, they may be constructed or modified dynamically by applications. Workflow instances have one or more owners with specific roles.
How iMIS Workflows work
As workflows progress and workflow rules are interpreted, work items (or tasks) are generated. Tasks are generally assigned to specific individual or process queues. Automatic processes are executed without human intervention. People-oriented queues show as tasks to your users. Tasks are never deleted; only marked complete. Tasks record time and, in some cases, effort for completion. The analysis of task data performance data can be a good source of information for process improvement.
The workflow itself can carry state data, document attachments, references to customers and their roles.
Workflows can run totally off their static definitions, or be created or modified by runtime processes.
Workflows are always used for system processes like “print invoices”, print AR statements, and so on. Since workflows are extensible, field users can add or subtract steps to these processes. Workflows are used to move most all of the older hard-coded processes like “print invoice”, “convert order”, “do due billing run” from hard-coded processes to extensible processes and allow installers to mold these processes to customer needs in a consistent way.
Workflows can be executed in a number of environments. They can run silently in the background as queues of work are worked off by the workflow engine’s background and scheduled processes, or can be run interactively. In the interactive situation, a standard dialog, similar to an installer dialog, displays progress and asks for intervention as required.
An initial implementation of the workflow engine exists in Process Manager. However, that implementation did not implement business rules or automatic application execution.